Bridge and asynchronous channel based bus to provide ui-to-ui asynchronous communication

ABSTRACT

In a system and method for providing UI-to-UI asynchronous communication, a bridge is coupled to an asynchronous channel based bus that has at least one Galactic channel. The bridge receives each message on the Galactic channel, and converts each message from a channel message format used by the Galactic channel to a common message format. The bridge utilizes a socket to broadcast each converted message to, and receive messages from, the one or more other bridges. The bridge determines that a message received from the one or more other bridges is destined for the Galactic channel. The bridge converts the message into the channel message format used by the Galactic channel. The bridge distributes the converted message to the at least one Galactic channel.

RELATED APPLICATIONS

This application is related to co-pending U.S. application Ser. No.______, filed on ______, entitled “An Asynchronous Channel Based BusArchitecture Enabling Decoupled Services,” by Dave Shanley, havingAttorney Docket No. D661.02, and assigned to the assignee of the presentapplication.

This application is related to co-pending U.S. application Ser. No.______, filed on ______, entitled “A Bridge, an Asynchronous ChannelBased Bus, and a Message Broker to Provide Asynchronous Communication,”by Dave Shanley, having Attorney Docket No. D661.03, and assigned to theassignee of the present application.

This application is related to co-pending U.S. application Ser. No.______, filed on ______, entitled “Schema To Ensure Payload Validity ForCommunications On An Asynchronous Channel Based Bus,” by Dave Shanley,having Attorney Docket No. D661.04, and assigned to the assignee of thepresent application.

BACKGROUND

Virtual-machine technology essentially abstracts the hardware resourcesand interfaces of a computer system on behalf of one or multiple virtualmachines, each comprising one or more application programs and anoperating system. The recent emergence of cloud computing services canprovide abstract interfaces to enormous collections of geographicallydispersed data centers, allowing computational service providers todevelop and deploy complex Internet-based services that execute on tensor hundreds of physical servers through abstract cloud-computinginterfaces.

Within virtual servers as well as physical servers, virtual machines andvirtual applications can be moved among multiple virtual or physicalprocessors in order to facilitate load balancing and to co-locatecompatible virtual machines and virtual applications with respect tovirtual and physical processors. Similarly, virtual machines and virtualapplications can be moved among the virtual servers within a virtualdata center as well as among physical servers within the underlyingphysical hardware within which virtual data centers are constructed.Migration of virtual machines and virtual applications within virtualdata centers can also be used for load balancing, fault tolerance andhigh availability, and for many other purposes.

Building a user interface (UI) that shows the realtime state of adistributed system, or a suite of products is hard.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings, which are incorporated in and form a part ofthe Description of Embodiments, illustrate various embodiments of thesubject matter and, together with the Description of Embodiments, serveto explain principles of the subject matter discussed below. Unlessspecifically noted, the drawings referred to in this Brief Descriptionof Drawings should be understood as not being drawn to scale. Herein,like items are labeled with like item numbers.

FIG. 1 illustrates an example computer system upon which embodiments ofthe present invention can be implemented.

FIG. 2 illustrates an example cloud-based computing environment uponwhich embodiments described herein may be implemented.

FIG. 3 illustrates a view of an example user interface for a cloud-basedvirtualization infrastructure upon which embodiments described hereinmay be implemented.

FIG. 4 illustrates a system having a bridge and an asynchronous channelbased bus to provide UI-to-UI asynchronous communication, in accordancewith various embodiments.

FIG. 5 illustrates the architecture for a bridge transparently extendinga bus between two applications, in accordance with various embodiments.

FIG. 6 illustrates the architecture for a bridge transparently extendinga bus to and from the message broker, in accordance with variousembodiments.

FIG. 7 illustrates a flow diagram of a method for using a bridge and anasynchronous channel based bus to provide UI-to-UI asynchronouscommunication, according to various embodiments.

DESCRIPTION OF EMBODIMENTS

Reference will now be made in detail to various embodiments of thesubject matter, examples of which are illustrated in the accompanyingdrawings. While various embodiments are discussed herein, it will beunderstood that they are not intended to limit to these embodiments. Onthe contrary, the presented embodiments are intended to coveralternatives, modifications and equivalents, which may be includedwithin the spirit and scope the various embodiments as defined by theappended claims. Furthermore, in this Description of Embodiments,numerous specific details are set forth in order to provide a thoroughunderstanding of embodiments of the present subject matter. However,embodiments may be practiced without these specific details. In otherinstances, well known methods, procedures, components, and circuits havenot been described in detail as not to unnecessarily obscure aspects ofthe described embodiments.

Notation And Nomenclature

Some portions of the detailed descriptions which follow are presented interms of procedures, logic blocks, processing and other symbolicrepresentations of operations on data bits within a computer memory.These descriptions and representations are the means used by thoseskilled in the data processing arts to most effectively convey thesubstance of their work to others skilled in the art. In the presentapplication, a procedure, logic block, process, or the like, isconceived to be one or more self-consistent procedures or instructionsleading to a desired result. The procedures are those requiring physicalmanipulations of physical quantities. Usually, although not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated in an electronic device.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the description ofembodiments, discussions utilizing terms such as “connecting,”“displaying,” “receiving,” “providing,” “determining,” “generating,”“establishing,” “managing,” “extending,” “creating,” “migrating,”“effectuating,” or the like, refer to the actions and processes of anelectronic computing device or system such as: a host processor, aprocessor, a memory, a virtual storage area network (VSAN), avirtualization management server or a virtual machine (VM), amongothers, of a virtualization infrastructure or a computer system of adistributed computing system, or the like, or a combination thereof. Itshould be appreciated that the virtualization infrastructure may beon-premises (e.g., local) or off-premises (e.g., remote or cloud-based),or a combination thereof. The electronic device manipulates andtransforms data represented as physical (electronic and/or magnetic)quantities within the electronic device's registers and memories intoother data similarly represented as physical quantities within theelectronic device's memories or registers or other such informationstorage, transmission, processing, or display components.

Embodiments described herein may be discussed in the general context ofprocessor-executable instructions residing on some form ofnon-transitory processor-readable medium, such as program modules,executed by one or more computers or other devices. Generally, programmodules include routines, programs, objects, components, datastructures, etc., that perform particular tasks or implement particularabstract data types. The functionality of the program modules may becombined or distributed as desired in various embodiments.

In the figures, a single block may be described as performing a functionor functions; however, in actual practice, the function or functionsperformed by that block may be performed in a single component or acrossmultiple components, and/or may be performed using hardware, usingsoftware, or using a combination of hardware and software. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled artisans may implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the present disclosure. Also, the example mobile electronicdevice described herein may include components other than those shown,including well-known components.

The techniques described herein may be implemented in hardware,software, firmware, or any combination thereof, unless specificallydescribed as being implemented in a specific manner. Any featuresdescribed as modules or components may also be implemented together inan integrated logic device or separately as discrete but interoperablelogic devices. If implemented in software, the techniques may berealized at least in part by a non-transitory processor-readable storagemedium comprising instructions that, when executed, perform one or moreof the methods described herein. The non-transitory processor-readabledata storage medium may form part of a computer program product, whichmay include packaging materials.

The non-transitory processor-readable storage medium may comprise randomaccess memory (RAM) such as synchronous dynamic random access memory(SDRAM), read only memory (ROM), non-volatile random access memory(NVRAM), electrically erasable programmable read-only memory (EEPROM),FLASH memory, other known storage media, and the like. The techniquesadditionally, or alternatively, may be realized at least in part by aprocessor-readable communication medium that carries or communicatescode in the form of instructions or data structures and that can beaccessed, read, and/or executed by a computer or other processor.

The various illustrative logical blocks, modules, circuits andinstructions described in connection with the embodiments disclosedherein may be executed by one or more processors, such as one or moremotion processing units (MPUs), sensor processing units (SPUs), hostprocessor(s) or core(s) thereof, digital signal processors (DSPs),general purpose microprocessors, application specific integratedcircuits (ASICs), application specific instruction set processors(ASIPs), field programmable gate arrays (FPGAs), or other equivalentintegrated or discrete logic circuitry. The term “processor,” as usedherein may refer to any of the foregoing structures or any otherstructure suitable for implementation of the techniques describedherein. In addition, in some aspects, the functionality described hereinmay be provided within dedicated software modules or hardware modulesconfigured as described herein. Also, the techniques could be fullyimplemented in one or more circuits or logic elements. A general purposeprocessor may be a microprocessor, but in the alternative, the processormay be any conventional processor, controller, microcontroller, or statemachine. A processor may also be implemented as a combination ofcomputing devices, e.g., a combination of an SPU/MPU and amicroprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with an SPU core, MPU core, or any othersuch configuration.

Overview of Discussion

Discussion begins with a description of an example computer systemenvironment, upon which embodiments of the present invention may beimplemented. An example cloud-based computing environment, upon whichembodiments of the present invention may be implemented, is thendiscussed. An example UI is then described. An example system having abridge and an asynchronous channel based bus to provide UI-to-UIasynchronous communication, in accordance with various embodiments, arethen described.

Modern computing can be considered to be a collection of many differentlevels of abstraction above the physical computing-hardware level thatincludes physical computer systems, data-storage systems and devices,and communications networks.

A UI provides a visual representation of the state of a system. It's away for a user to see and change the current state of that system. Thebiggest challenge when attempting to build integrated UIs betweenseparate products or distributed systems, is sourcing, delivering andsharing multiple streams of realtime data between multiple layers ofmiddleware and the UI's they are serving. Typically, companies such asVMware employ private API's or SDK's to pull or push data to and fromproducts that talk to one another; those products then provide privateAPI's to a UI that renders the data to the user.

Example embodiments described herein provide a method for using a bridgeand an asynchronous channel based bus (AKA Bifröst) to provide UI-to-UI,Service-to-UI, and UI-to-Service asynchronous communication. In oneembodiment, Bifröst is a reusable component written in TypeScript. Itmakes use of technologies such as Simple (or Streaming) Text OrientatedMessaging Protocol (STOMP), ReactiveX/Stream based programming, and thelike, to build a completely decoupled, fully asynchronous, distributedmessage bus. The Bifröst allows any UI, microservice, or platform tosend and receive asynchronous messages between one another all withoutrequiring any additional technology or custom integrations. Existing andlegacy applications & middleware written in any language (e.g., Java)can also use the Bifröst architecture to send and receive messages toUI's or other services. In one embodiment, the library is delivered bynpm and integrates seamlessly into any JavaScript/Typescript or Angular4+ based application. In another embodiment, the Bifröst is written inJava and can be used by any Java 8+ application. In one embodiment, theAPI's match as closely as possible.

In general, STOMP refers to an interoperable wire format used todramatically simplify the communication between clients and messagebrokers across a variety of languages, brokers and platforms. It isdesigned as an alternative to more complex protocols like advancedmessage queuing protocol (AMQP).

Importantly, the embodiments of the present invention, as will bedescribed below, provide an approach for UI-to-UI, Service-to-UI, andUI-to-Service asynchronous communication which differs significantlyfrom the conventional processes used in UI communication. Inconventional approaches, UI frameworks allow for dependency injectionacross UI's. Normally developers create services that are injected intocontrollers. Services often have other services injected into them also.Whilst this pattern works for smaller applications, it quickly becomesunmanageable with large applications like the vSphere Webclient.Services and views quickly become tightly coupled and modularity becomesdifficult to maintain when tens of services are injected in multipleareas. Such conventional approaches are deleteriously affected by APIupdates or changes, tedious, time-consuming, and often result in clunkyclient side code with API work arounds.

Instead, the present embodiments, as will be described and explainedbelow in detail, provide a previously unknown procedure for utilizing abridge and an asynchronous channel based bus (Bifröst) to provideUI-to-UI, Service-to-UI, and UI-to-Service asynchronous communication.The asynchronous channel based bus provides two core services. The firstis to allow the dynamic creation and subsequent destruction of channelswithin the bus. The second is to allow any actor to publish and/orsubscribe to those channels and broadcast messages. The bridge is acompletely decoupled module that depends only on the bus. Its functionis to extend specific channels on the bus out to an application'smessage broker, platform or designated microservice. These extendedchannels are referred to herein as Galactic channels.

As will be described in detail, the various embodiments of the presentinvention do not merely implement conventional UI-to-UI communicationprocesses on a computer. Instead, the various embodiments of the presentinvention, in part, provide a previously unknown procedure for providinga bridge and an asynchronous channel based bus in combination to provideUI-to-UI asynchronous communication. Hence, embodiments of the presentinvention provide a novel process for UI-to-UI asynchronouscommunication which is necessarily rooted in computer technology toovercome a problem specifically arising in the realm of integrated UserInterfaces (UI) between separate products or distributed systems.

Example Computer System Environment

With reference now to FIG. 1, all or portions of some embodimentsdescribed herein are composed of computer-readable andcomputer-executable instructions that reside, for example, incomputer-usable/computer-readable storage media of a computer system.That is, FIG. 1 illustrates one example of a type of computer (computersystem 100) that can be used in accordance with or to implement variousembodiments which are discussed herein. It is appreciated that computersystem 100 of FIG. 1 is only an example and that embodiments asdescribed herein can operate on or within a number of different computersystems including, but not limited to, general purpose networkedcomputer systems, embedded computer systems, routers, switches, serverdevices, client devices, various intermediate devices/nodes, stand alonecomputer systems, media centers, handheld computer systems, multi-mediadevices, virtual machines, virtualization management servers, and thelike. Computer system 100 of FIG. 1 is well adapted to having peripheraltangible computer-readable storage media 102 such as, for example, anelectronic flash memory data storage device, a floppy disc, a compactdisc, digital versatile disc, other disc based storage, universal serialbus “thumb” drive, removable memory card, and the like coupled thereto.The tangible computer-readable storage media is non-transitory innature.

System 100 of FIG. 1 includes an address/data bus 104 for communicatinginformation, and a processor 106A coupled with bus 104 for processinginformation and instructions. As depicted in FIG. 1, system 100 is alsowell suited to a multi-processor environment in which a plurality ofprocessors 106A, 106B, and 106C are present. Conversely, system 100 isalso well suited to having a single processor such as, for example,processor 106A. Processors 106A, 106B, and 106C may be any of varioustypes of microprocessors. System 100 also includes data storage featuressuch as a computer usable volatile memory 108, e.g., random accessmemory (RAM), coupled with bus 104 for storing information andinstructions for processors 106A, 106B, and 106C. System 100 alsoincludes computer usable non-volatile memory 110, e.g., read only memory(ROM), coupled with bus 104 for storing static information andinstructions for processors 106A, 106B, and 106C. Also present in system100 is a data storage unit 112 (e.g., a magnetic or optical disc anddisc drive) coupled with bus 104 for storing information andinstructions. System 100 also includes an alphanumeric input device 114including alphanumeric and function keys coupled with bus 104 forcommunicating information and command selections to processor 106A orprocessors 106A, 106B, and 106C. System 100 also includes an cursorcontrol device 116 coupled with bus 104 for communicating user inputinformation and command selections to processor 106A or processors 106A,106B, and 106C. In one embodiment, system 100 also includes a displaydevice 118 coupled with bus 104 for displaying information.

Referring still to FIG. 1, display device 118 of FIG. 1 may be a liquidcrystal device (LCD), light emitting diode display (LED) device, cathoderay tube (CRT), plasma display device, a touch screen device, or otherdisplay device suitable for creating graphic images and alphanumericcharacters recognizable to a user. Cursor control device 116 allows thecomputer user to dynamically signal the movement of a visible symbol(cursor) on a display screen of display device 118 and indicate userselections of selectable items displayed on display device 118. Manyimplementations of cursor control device 116 are known in the artincluding a trackball, mouse, touch pad, touch screen, joystick orspecial keys on alphanumeric input device 114 capable of signalingmovement of a given direction or manner of displacement. Alternatively,it will be appreciated that a cursor can be directed and/or activatedvia input from alphanumeric input device 114 using special keys and keysequence commands. System 100 is also well suited to having a cursordirected by other means such as, for example, voice commands. In variousembodiments, alphanumeric input device 114, cursor control device 116,and display device 118, or any combination thereof (e.g., user interfaceselection devices), may collectively operate to provide a UI 130 underthe direction of a processor (e.g., processor 106A or processors 106A,106B, and 106C). UI 130 allows user to interact with system 100 throughgraphical representations presented on display device 118 by interactingwith alphanumeric input device 114 and/or cursor control device 116.

System 100 also includes an I/O device 120 for coupling system 100 withexternal entities. For example, in one embodiment, I/O device 120 is amodem for enabling wired or wireless communications between system 100and an external network such as, but not limited to, the Internet.

Referring still to FIG. 1, various other components are depicted forsystem 100. Specifically, when present, an operating system 122,applications 124, modules 126, and data 128 are shown as typicallyresiding in one or some combination of computer usable volatile memory108 (e.g., RAM), computer usable non-volatile memory 110 (e.g., ROM),and data storage unit 112. In some embodiments, all or portions ofvarious embodiments described herein are stored, for example, as anapplication 124 and/or module 126 in memory locations within RAM 108,computer-readable storage media within data storage unit 112, peripheralcomputer-readable storage media 102, and/or other tangiblecomputer-readable storage media.

Example Cloud-Based Computing Environment

FIG. 2 illustrates an example cloud-based computing environment 200 uponwhich embodiments described herein may be implemented. In thecloud-computing paradigm, computing cycles and data-storage facilitiesare provided to organizations and individuals by cloud-computingproviders. In addition, larger organizations may elect to establishprivate cloud-computing facilities in addition to, or instead ofsubscribing to computing services provided by public cloud-computingservice providers. In FIG. 2, a system administrator for anorganization, using a computer system 202, accesses the organization'slocal virtualization infrastructure 204 (e.g., a private cloud) througha local network 206 and also accesses, through the Internet 210, aremote virtualization infrastructure 212 (e.g., a public cloud). Invarious embodiments, access to local virtualization infrastructure 204is through a private cloud services interface and/or access to remotevirtualization infrastructure 212 is through a public cloud servicesinterface.

It should be appreciated that local virtualization infrastructure 204can be any type of virtualization infrastructure (e.g., VMwarevSphere™), that remote virtualization infrastructure 212 can be any typeof virtualization infrastructure (e.g., VMware vCloud Air) and thatvirtualization infrastructure management system 208 can be any type ofsystem for managing and creating components of a virtualizationinfrastructure (e.g., VMware vSphere™ VCenter™ or vCloud Air WebPortal).

For example, the administrator can, in either the case of localvirtualization infrastructure 204 or remote virtualizationinfrastructure 212, using virtualization infrastructure managementsystem 208, configure virtual computer systems and even entire virtualdata centers and launch execution of application programs on the virtualcomputer systems and virtual data centers in order to carry out any ofmany different types of computational tasks. As one example, a smallorganization may configure and run a virtual data center within a publiccloud that executes web servers to provide an e-commerce interfacethrough the public cloud to remote customers of the organization, suchas a user viewing the organization's e-commerce web pages on a remotecomputer system 216.

Cloud-computing facilities may provide computational bandwidth anddata-storage services much as utility companies provide electrical powerand water to consumers. Cloud computing provides enormous advantages tosmall organizations without the resources to purchase, manage, andmaintain in-house data centers. Such organizations can dynamically addand delete virtual computer systems from their virtual data centerswithin public clouds in order to track computational-bandwidth anddata-storage needs, rather than purchasing sufficient computer systemswithin a physical data center to handle peak computational-bandwidth anddata-storage demands. Moreover, small organizations can completely avoidthe overhead of maintaining and managing physical computer systems,including hiring and periodically retraining information-technologyspecialists and continuously paying for operating-system anddatabase-management-system upgrades. Furthermore, cloud-computinginterfaces allow for easy and straightforward configuration of virtualcomputing facilities, flexibility in the types of applications andoperating systems that can be configured, and other functionalities thatare useful even for owners and administrators of private cloud-computingfacilities used by a single organization.

Example User Interface for a Cloud-Based Virtualization Infrastructure

FIG. 3 illustrates a view of an example user interface 300 for acloud-based virtualization infrastructure, in accordance with variousembodiments.

It should be appreciated that UIs may be designed to provide aparticular interactive experience based on the type of informationpresented and/or received through the UI. Moreover, a UI may include oneor more different type of interactive elements for receivinginformation. For example, the interactive elements may include, withoutlimitation: buttons, widgets, controls, text boxes, radio buttons,tri-state boxes, list boxes, numerical input boxes, tool bars, sliders,spinners, drop-down lists, accordion lists, menus, menu bars, tool bars,icons, scroll bars, labels, tooltips, balloon help, status bars,progress bars, etc. The types of interactive elements included in a UIare typically design decisions, where a UI designer might attempt toprovide particular elements to present and/or receive particular typesof information. For example, a simple UI may include a drop-down list,where a user would select an item from the drop down list.

FIG. 3 illustrates a view 310 of an example introductory screen of UI300. View 310 is displayed in response to receiving a user access to acloud-based virtualization infrastructure service management pluginthrough UI 300. For example, as illustrated, UI 300 is associated withthe VMware's vSphere Web Client for managing a local virtualizationinfrastructure. View 310 provides access to a plugin (e.g., VMware'svCloud Air vSphere Client Plug-in as illustrated) for connecting a localvirtualization infrastructure to a cloud-based virtualizationinfrastructure. As illustrated, view 310 provides explanatoryinformation on the use and operation of the cloud-based virtualizationinfrastructure service management plugin, including an explanation videoand related links. It should be appreciated that the explanatoryinformation as illustrated in view 310 is an example, and that any typeof cloud-based virtualization infrastructure aspects and services may beprovided.

Bus

FIG. 4 shows a simplified two peer system 400 in accordance with anembodiment. FIG. 4 includes a bus 410, a consumer 420, a producer (orpeer) 430, a bus channel 440, request 455 and response 460. The use ofbus 410 offers architectures a simple, yet elegant way to shareinformation between publishers and subscribers across a local ordistributed system. Bus 410 creates a system of consumer(s) 420 andproducer(s) 430. The asynchronous nature of bus 410 is ideal for UI's,as well as microservices.

In one embodiment, bus 410 creates a peer to peer (P2P) architecturebetween all components, thereby removing the need to keep adding hops toa call stack and increasing blocked calls. Bus 410 allows each messageto be performed in small asynchronous units of work, that clears thecall stack and lets another actor process or send a message, or the UIto re-render a component. Bus 410 essentially allows every message to beprocessed as a cycle of the event loop (which is also message based)instead of being a blocked call in a chain.

The channel based bus 410 that provides two core services. The first isto allow the dynamic creation and subsequent destruction of channel(s)440 within bus 410. The second is to allow any actor (e.g., consumer(s)420 and/or producer(s) 430) to publish and/or subscribe to thosechannel(s) 440 and broadcast messages. Operation is analogous with achat system like Slack or IRC. A channel 440 can be requested by anyactor bus 410 is visible to, if the channel 440 doesn't exist, it iscreated. In one embodiment, when there are no more subscribers to achannel 440, the channel 440 is destroyed. Bus 410 allows actors whichmainly consist of services and controllers, to send and receive messages455 and 460 between each other. These messages 455 and 460 can be anytype of data such as objects, strings, arrays, streams, collections, ormaps.

As stated herein, actors can be considered consumer(s) 420, producer(s)430, or both. Consumer(s) 420 can issue requests 416 and listen forresponses 419, producer(s) 430 can listen for requests 417 and issueresponses 418, As long as an actor can see bus 410, they are able tocommunicate with any other actor within the local or remote system.

In one embodiment, a consumer(s) 420 (or something that needs data) canmake a request for data by sending an outbound request message 455 tothe topic channel 440 on bus 410. Request message 455 will be broadcastto any subscribed actors listening to request messages on that samechannel 440. In this example, # metrics is used as the topic channel(s)440.

A producer(s) 430 provides data and listens for outbound requests on itstopic channel 440. Once the producer(s) 430 receives the request message455, it can perform whatever operations it requires. When theproducer(s) 430 is ready, it sends an inbound response message 460 tothe topic channel 440 on bus 410. The consumer(s) 420 is subscribed to #metrics channel 440 also, but is only listening to inbound responsemessages 460. The consumer(s) 420 will pick up the broadcast message andbe able to continue on.

In one embodiment, all of bus 410 activity is handled in a non-blockingand asynchronous manner. In one embodiment, bus 410 makes use of aReactiveX framework as the foundation. This facilitates theasynchronous/stream based communication. In so doing, bus 410 enablestrue decoupling of components and services inside applications. Bus 410becomes the only dependency and is also context neutral. In other words,bus 410 is unaware of the application(s) it's embedded in.

For example, consumer(s) 420 should be able to hop into a channel 440,send a request on the channel. Meanwhile, producer(s) 430 that can meetthe request is also listening on the channel. The producer(s) 430receives the request 455 and then provides the request response 460 onthe channel. Consumer 420 will receive the request response 460 on thechannel.

Thus, in one embodiment, any component on the bus 410 can talk to eachother. They can talk on private channels or on public channels.

For example, a REST service (e.g., producer 430) listens to messages ona REST channel designed for components (e.g., consumer 420) that want tosend out a REST response to an API. A component will say on a RESTchannel, I want to make a call, go get me some VMs or go get me someusers. The component (e.g., consumer 420) that sends the request willthen go back to idle. The REST service (e.g., producer 430) will takethe message and make the XHR/HTTP call needed to go get the data; oncethe data is returned to the REST service, the REST service will take thereturned data and put the data on the message bus on the REST channel.The component that made the call will note the returned data on the RESTchannel.

In so doing, the component that made the call does not need to knowabout the REST service, HTTP or the API. Doesn't need to know where thedata comes from, how it is processed, or who gets it. It merely needs tolisten for responses on the channel. In other words, services,controllers and views have all been decoupled. Instead of communicatingwith each other through dependency injection or the like, theycommunicate through message channels on the bus 410. The messaging isall asynchronous so there is no sitting and waiting, only when somethingelse comes down the channel will the application wake up and starthandling it.

In one embodiment, the component can send the request on a first channel(e.g., a public channel) and further request that the response be senton a second separate channel (e.g., a private channel).

In one embodiment, there is no global list of channels, no whitelist ofchannels or the like received by the components coupled with bus 410. Itis a multi-cast communication channel that can be created on demand by acreator 420 or producer 430. If no one is listening on the channel thennothing will be sent and the messages are dropped from the bus.

In another embodiment, a request to bus 410 can be made by a creator 420and/or producer 430 to provide the different channels available on thebus. In another embodiment, there may be a registration, a list ofpre-defined channels, etc.

Bridge

FIG. 5 illustrates the architecture 500 for a bridge 510 transparentlyextending bus 410 between two applications (e.g., application A andapplication B). In one embodiment, bridge 510 is a completely decoupledmodule that depends only on bus 410. The function of bridge 510 is toextend specific channel(s) 440 on bus 410 out to an application'smessage broker 555 (broker 555 may be a broker, platform, designatedmicroservice or the like). In general, these extended channel(s) 440 arereferred to herein as Galactic channels.

In one embodiment, bridge 510 operates by making use of a monitor API520 that bus 410 provides. Monitor API 520 broadcasts channel 440 eventsrelating to creation, subscription, unsubscription and destruction.Events relating to Galactic channels are what bridge 510 really caresabout. In one embodiment, bridge 510 ignores all non-Galactic events. Inone embodiment, to identify # local vs Galactic or extended channel(s)440, the following hash convention plus snakecase is used: #local-channel vs Galactic-channel (no hash). However, it should beappreciated that there are no specific limitations on the naming oflocal vs Galactic channels, the previous convention is merely one of anumber of different possible ways to delineate the difference betweenthe local and Galactic channel.

FIG. 6 illustrates the architecture 600 for a bridge 510 transparentlyextending a bus to and from the message broker. One embodimentillustrates how bridge 510 transparently subscribes to Galactic channel640 g and then proxies request message(s) 455 and response message(s)460 to and from the message broker 555. It achieves this by listeningfor Galactic channel 640 g traffic, converting request message 455 andresponse message 460 to and from STOMP frames 610 and then sending andreceiving messages 455 and 460 over a Socket 620. It further ignoreslocal channel 640I traffic.

In one embodiment, socket 620 is a WebSocket. In general, when a livefeed/stream is needed, a browser (or platform) can use sockets (e.g.,WebSockets or regular sockets) to create a bidirectional string (it isnormally unidirectional). Live feed via the socket 620 is used to sendlive feed updates (metric, notification, alert, network change, etc.) tothe UI and for the UI be able to capture the live feed updates.

When bridge 510 receives a Galactic channel 640 g event, it will act asa global broker for that channel and extend the channel out to messagebroker 555, another service that supports STOMP, or the like. In oneembodiment, bus 410 has no knowledge that bridge 510 is operating,neither do the peers (e.g., producer(s) 430 and consumer(s) 420) sendingrequests and responses. Bridge 510 handles all of the proxying ofmessages transparently. In other words, bridge 510 acts as the gluebetween bus 410 and multiple STOMP enabled message broker(s) 555,connected over WebSocket 620.

In one embodiment, bridge 510 has benefits that hide and abstract a lotof complexity. For example, bridge 510 transparently handles all of theWebSocket 620 and session management across multiple message broker(s)555. In one embodiment, bridge 510 reads raw STOMP frames being sentfrom message broker 555 and then parses and distributes the messages tothe Galactic channel(s) 640 g that match the destination of the message.In order to maintain the Galactic channel organization, bridge 510subscribes to a topic or queue that matches the name of the Galacticchannel 640 g on bus 410. Once subscribed, bridge 510 will relay anymessages 455 and 460 sent to or from any Galactic channel 640 g and themapped topics/queues.

In one embodiment, bridge 510 handles message broker 555 communicationsvia an interoperable wire format such as STOMP 1.2. That is, messages455 and 460 sent on Galactic channel(s) 640 g are marshalled andunmarshalled into STOMP commands that are both transmitted and receivedby message broker 555. In one embodiment, bus 410 is not aware of STOMPcommands; instead, bridge 510 takes care of it all.

For example, when data is desired (e.g., metrics, Virtual machines, userdata, etc.), the component can subscribe to all the channels locally,bridge 510 will extend the channels to their own topics on the messagebroker 555, and, in one embodiment, all through a single socket 620.That is, in one embodiment, every subscribed channel by the component ispassed through the single socket 620.

The bridge will receive the response messages from the message brokerand then provide the response messages to the local channel related tothe initial request. Thus, bridge 510 allows multiple systems to talk toeach other without knowing they are talking to remote systems. Theythink they are talking to a local message bus but they are actuallyextended to any number of systems.

For example, they are sending things on local channels 640I or Galacticchannels 640 g, if it is sent on a Galactic channel 640 g, the monitorAPI 520 realizes it is a message 455 on a Galactic channel 640 g, takesthe message 455 to bridge 510 through the STOMP client 610 and over theWebSocket 620 and transports it to the broker 555 and anyone listening.A listening component coupled with the broker/platform 555 will receivethe message 455 and send a response 460 back to the WebSocket 620,through the STOMP client 610 up to the bridge 510 and the bridge 510will put the response 460 on the proper channel 640 g.

In one embodiment, bus 410 and bridge 510 don't require any additionaltechnologies other than the language they are written in and theReactiveX framework to operate. An existing application message broker555 (like Spring) could instantly be adapted to communicate over STOMP.In one embodiment, bus 410 and bridge 510 inside the Bifröst is writtenin TypeScript and Java and depends on reactive extensions for JavaScript(RxJS) and Java (RxJava). In general, the STOMP implementation does notrequire any third party libraries as it is custom built, such as byusing the STOMP 1.2 specification.

Since service call chaining no longer exists, all operations can happenasynchronously. This not only provides a huge performance improvementover blocking chained calls, but it also allows developers to build newarchitectures that focus on a stream and event based/reactive world.Further, it facilitates designers to construct new experiences based onstream driven data, particularly if the data is live streaming via theBridge.

In one embodiment, services can make requests and handle responses withjust a few lines of code. For example, request message(s) 455 andresponse message(s) 460 can be handled with class methods, or closures.E.g.

const bus = new MessagebusService( ); /* will log ‘response: echo[hello!]’ */ bus.respondOnce(“#local-channel”).generate(  (request:string) => {   return “echo [“ + request + ”]”;  } );bus.requestOnce(“#local-channel”, “hello!”).handle(  (response: string)=> {   console.log(“response: ” + echo);  } };

The Bridge allows components using the Bus to treat distributed(Galactic) channels as regular channel(s) 440; the process of how thosemessages are broadcast to remote consumers is completely abstracted awayfrom the developer. That is, there is no requirement to learn thecomplexities of WebSocket 620 communications, STOMP, or handlingmultiple streams with data arriving asynchronously.

Individual components inside a UI or service can communicate directlywith other services or UI components locally or remotely via bridge 510.No other component needs to know about the conversations happeningbetween other UI components, message broker(s) 555 and headlessmicroservices. This allows a selection menu in a UI to request data overa Galactic channel 640 g from a microservice running somewhere. Only thedropdown component and the microservice would know about theconversation and the rest of the application could remain idle.

In one embodiment, bridge 510 has a socket watchdog that will reconnectif there is an error or a disconnect between bridge 510 and messagebroker 555.

The Bifröst architecture allows a browser based UI to talk directly to amessage broker 555 over WebSocket 620. It also allows any othernon-browser based application or microservice to communicate with amessage broker 555 using standard sockets. In both cases, the samesimple protocol to send and receive messages is used.

In other words, using bridge 510, the service will send the informationon the channel, the bridge will be able to translate the information(via the STOMP) before it is put on the broker/platform and translatethe response before it is put back on the channel to the service. In sodoing, each different service can universally communicate. Therebyproviding a real-time distributed architecture where producers andconsumers can talk to each other asynchronously by any number of remotesystems and local systems. Thus, using Bifröst, the concept of local andremote no longer matters; resulting in scalability, distribution,extension, speed, performance, etc.

That is, bridge 510 allows the application to connect to multiplemessage broker(s) 555 at the same time and create and consume multiplestreams of data that can be bound together to create new streams.Message broker(s) 555 can be distributed/relayed and expand Galacticchannels 640 g out across clouds and DMZ's. Moreover, messages 455 and460 can be relayed between message broker(s) 555 to connect services andUI's across different networks, all transparently.

In general, broker 555 can be a single broker or a pool of brokers.Messages are stateless. Further, in one embodiment, the message(s) arequeued by the broker so that the component will not miss a message if itis down/away/occupied, etc.

Example Methods of Operation

FIG. 7 illustrates a flow diagram 700 of an example method for providingUI-to-UI, Service-to-UI, and UI-to-Service asynchronous communication,according to various embodiments. Procedures of the method will bedescribed with reference to elements and/or components of FIGS. 4-6. Itis appreciated that in some embodiments, the procedures may be performedin a different order than described, that some of the describedprocedures may not be performed, and/or that one or more additionalprocedures to those described may be performed. Flow diagram 700includes some procedures that, in various embodiments, are carried outby one or more processors under the control of computer-readable andcomputer-executable instructions that are stored on non-transitorycomputer-readable storage media. It is further appreciated that one ormore procedures described in flow diagram 700 may be implemented inhardware, or a combination of hardware with firmware and/or software.

With reference to FIG. 7, at 710 of flow diagram 700 and to FIG. 5, oneembodiment monitors, via a first bridge 520 a, at least one Galacticchannel 440 a on a first asynchronous channel based bus 410 a coupledwith a first UI 300.

In one embodiment, a dynamic creation of a plurality of channels 440within the first bus 410 a and the second asynchronous channel based bus410 b are allowed. Further, a subsequent destruction of one or more ofthe plurality of channels 440 within first bus 410 a and the second bus410 b is also allowed.

One embodiment allows a service (e.g., consumer(s) 420 and/orproducer(s) 430) to publish to, and receive from, any of the pluralityof channels of the first bus 410 a and/or second bus 410 b andadditionally allows a controller (e.g., consumer(s) 420 and/orproducer(s) 430) to publish to, and receive from, any of the pluralityof channels 440 of the first bus 410 a and/or second bus 410 b.

In one embodiment, first bus 410 a broadcasts, via a monitor API 520 a,channel events including creation, subscription, unsubscription anddestruction for the first bus 410 a. Similarly, second bus 410 bbroadcasts, via a monitor API 520 b, channel events including creation,subscription, unsubscription and destruction for the second bus 410 b.

Referring now to 715 of flow diagram 700, one embodiment receives, atthe first bridge 510 a, every message (e.g., message 455) sent on the atleast one Galactic channel 440 a. For example, the first bridge 510 awill monitor the broadcast of the monitor API 520 a for every Galacticchannel event on the first bus 410 a. In one embodiment, the firstbridge 510 a will ignore the broadcast of the monitor API 520 a withrespect to local channel events.

In one embodiment, the first bridge 510 a will monitor every Galacticchannel 440 on first bus 410 a and receive every message sent on everyGalactic channel of first bus 410 a. Similarly, the second bridge 510 bwill monitor every Galactic channel 440 on second bus 410 b and receiveevery message sent on every Galactic channel of second bus 410 b.

With reference to 720 of flow diagram 700, one embodiment converts, viaa message translator (e.g., STOMP client 610 of FIG. 6) coupled with thefirst bridge 510, each message 455 sent on the at least one Galacticchannel from a message format used by the at least one Galactic channelinto a common format.

In one embodiment, the first bridge 510 a will convert, via the messagetranslator (e.g., STOMP client 610) coupled with the first bridge 510,every message received from every Galactic channel 440 from the messageformat used by each Galactic channel of first bus 410 a to a commonmessage format.

Referring now to 725 of flow diagram 700, one embodiment sends, via aWebSocket (e.g., 620 of FIG. 6) coupled with the first bridge 510 a,each common format message to a second bridge 510 b.

With reference to 730 of flow diagram 700, one embodiment receives, viaa second WebSocket 620 coupled with the second bridge 510 b, the commonformat message from the first bridge 510 a.

Referring now to 735 of flow diagram 700, one embodiment determines, atthe second bridge 510 b, that the message 455 received from the firstbridge 510 a is destined for a Galactic channel on second bus 410 bcoupled with a second UI. The second bus 410 b monitored by the secondbridge 510 b.

If there are pluralities of messages 455 and 460 received from the firstbridge 510 a, the second bridge 510 b will determine which of theplurality of messages 455 and 460 are destined for which specificGalactic channels on second bus 410 b.

Moreover, if there are pluralities of Galactic channels on second bus410 b, the second bridge will further determine which of the pluralityof messages are destined for which of the pluralities of Galacticchannels on second bus 410 b.

With reference to 740 of flow diagram 700, one embodiment converts, viaa message translator (e.g., STOMP client 610) coupled with the secondbridge 510 b, the common format message 455 received from the firstbridge 510 a to a message format used by the Galactic channel 440 b onsecond bus 410 b.

Referring now to 745 of flow diagram 700, one embodiment distributes,via the second bridge 510 b, the converted message 455 received from thefirst bridge 510 a to the Galactic channel 440 b on second bus 410 b.

Conclusion

The Bifröst provides a solution to the single pane of glass UI problem.Embodiments provide a mental shift for developers over tostream/reactive based programming a lot easier. It facilitates morerapid development of complex reactive style experiences without theinvestment required to understand the lower level intricacies.

The Bifröst provides a turbocharger for UI and service architectures insoftware as a service (SaaS) based world that demands applications andservices operate in a distributed manner.

The examples set forth herein were presented in order to best explain,to describe particular applications, and to thereby enable those skilledin the art to make and use embodiments of the described examples.However, those skilled in the art will recognize that the foregoingdescription and examples have been presented for the purposes ofillustration and example only. The description as set forth is notintended to be exhaustive or to limit the embodiments to the preciseform disclosed. Rather, the specific features and acts described aboveare disclosed as example forms of implementing the claims.

Reference throughout this document to “one embodiment,” “certainembodiments,” “an embodiment,” “various embodiments,” “someembodiments,” or similar term means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one embodiment. Thus, the appearances of suchphrases in various places throughout this specification are notnecessarily all referring to the same embodiment. Furthermore, theparticular features, structures, or characteristics of any embodimentmay be combined in any suitable manner with one or more other features,structures, or characteristics of one or more other embodiments withoutlimitation.

What is claimed is:
 1. A system comprising: an asynchronous channelbased bus having at least one Galactic channel; a first user interface(UI) coupled to the asynchronous channel based bus, the first UI to passmessages to and receive messages from a second UI on the at least oneGalactic channel; and a bridge coupled to the asynchronous channel basedbus, the bridge comprising: a message receiver to receive each messageon the at least one Galactic channel; a message translator to converteach message received from the at least one Galactic channel from achannel message format used by the at least one Galactic channel to acommon message format; a socket to broadcast each message converted tothe common message format to one or more other bridges, and receive atleast one message from the one or more other bridges; and a receivedmessage sorter to determine that the at least one message received fromthe one or more other bridges is destined for the at least one Galacticchannel, and provide the at least one message to the message translatorto convert the at least one message to the channel message format usedby the at least one Galactic channel; and the bridge to distribute theconverted message received from the one or more other bridges to the atleast one Galactic channel.
 2. The system of claim 1, wherein theasynchronous channel based bus allows a dynamic creation of one or moreof a plurality channels therein.
 3. The system of claim 1, wherein theasynchronous channel based bus allows a dynamic destruction of one ormore of a plurality of channels therein.
 4. The system of claim 3,wherein the asynchronous channel based bus allows an actor to publish toany of the plurality of channels.
 5. The system of claim 3, wherein theasynchronous channel based bus allows any actor to subscribe to any ofthe plurality of channels.
 6. The system of claim 1, wherein theasynchronous channel based bus further comprises: a monitor API, themonitor API broadcasts channel events including creation, subscription,unsubscription and destruction.
 7. The system of claim 6, wherein thebridge further comprises: a Galactic channel monitor to listen to themonitor API for Galactic channel events, the Galactic channel monitorignoring local channel events.
 8. The system of claim 1, wherein thebridge further comprises: a socket watchdog that will reconnect thebridge to the one or more other bridges after an error or a disconnect.9. The system of claim 1, wherein the common message format is a simpletext oriented messaging protocol (STOMP).
 10. The system of claim 1,wherein the asynchronous channel based bus is not aware that the bridgeis operating.
 11. The system of claim 1, wherein the asynchronouschannel based bus comprises a plurality of Galactic channels.
 12. Thesystem of claim 11, wherein the bridge communicates with each of theplurality of Galactic channels.
 13. The system of claim 1, wherein ahash convention plus snake-case is used to identify the at least oneGalactic channel.
 14. A computer-implemented method for providing userinterface (UI-to-UI asynchronous communication, saidcomputer-implemented method comprising: monitoring, via a first bridge,at least one Galactic channel on a first asynchronous channel based buscoupled with a first UI; receiving, at the first bridge, every messagesent on the at least one Galactic channel; converting, via a messagetranslator coupled with the first bridge, each message sent on the atleast one Galactic channel from a message format used by the at leastone Galactic channel into a common format; sending, via a firstWebSocket coupled with the first bridge, each common format message to asecond bridge; receiving, via a second WebSocket coupled with the secondbridge, the common format message from the first bridge; determining, atthe second bridge, that the message received from the first bridge isdestined for a Galactic channel on a second asynchronous channel basedbus coupled with a second UI, the second asynchronous channel based busmonitored by the second bridge; converting, via a message translatorcoupled with the second bridge, the common format message received fromthe first bridge to a message format used by the Galactic channel on thesecond asynchronous channel based bus; and distributing, via the secondbridge, the converted message received from the first bridge to theGalactic channel on the second asynchronous channel based bus.
 15. Thecomputer-implemented method of claim 14, further comprising: allowing adynamic creation of a plurality of channels within the firstasynchronous channel based bus and the second asynchronous channel basedbus, and allowing a subsequent destruction of one or more of theplurality of channels within the first asynchronous channel based busand the second asynchronous channel based bus.
 16. Thecomputer-implemented method of claim 14, further comprising: allowing aservice to publish to, and receive from, any of the plurality ofchannels of the first asynchronous channel based bus; and allowing acontroller to publish to, and receive from, any of the plurality ofchannels of the first asynchronous channel based bus.
 17. Thecomputer-implemented method of claim 14, further comprising:broadcasting, via a monitor API provided by the first asynchronouschannel based bus, channel events including creation, subscription,unsubscription and destruction; monitoring, via the first bridge, thebroadcast of the monitor API for every Galactic channel event on thefirst asynchronous channel based bus; and ignoring the broadcast of themonitor API with respect to local channel events.
 18. Thecomputer-implemented method of claim 14, further comprising: monitoring,via the first bridge, every Galactic channel on the first asynchronouschannel based bus; receiving, at the first bridge, every message sent onevery Galactic channel of the first asynchronous channel based bus; andconverting, via the message translator coupled with the first bridge,every message received from every Galactic channel from the messageformat used by each Galactic channel of the first asynchronous channelbased bus to a common message format.
 19. A system comprising: anasynchronous channel based bus having at least one Galactic channel, theasynchronous channel based bus having a monitor API, the monitor APIbroadcasts channel events including creation, subscription,unsubscription and destruction; a first user interface (UI) coupled tothe asynchronous channel based bus, the first UI to pass messages to andreceive messages from a second UI on the at least one Galactic channel;and a bridge coupled to the asynchronous channel based bus, the bridgecomprising: a Galactic channel monitor to listen to the monitor API forGalactic channel events, the Galactic channel monitor ignoring localchannel events. a message receiver to receive each message on the atleast one Galactic channel; a message translator to convert each messagereceived from the at least one Galactic channel from a channel messageformat used by the at least one Galactic channel to a common messageformat; a socket to broadcast each message converted to the commonmessage format to one or more other bridges, and receive at least onemessage from the one or more other bridges; and a received messagesorter to determine that the at least one message received from the oneor more other bridges is destined for the at least one Galactic channel,and provide the at least one message to the message translator toconvert the at least one message to the channel message format used bythe at least one Galactic channel; and the bridge to distribute theconverted message received from the one or more other bridges to the atleast one Galactic channel.
 20. The system of claim 19, wherein theasynchronous channel based bus allows: a dynamic creation of one or moreof a plurality channels; a dynamic destruction of one or more of theplurality of channels; an actor to publish to any of the plurality ofchannels; and any actor to subscribe to any of the plurality ofchannels.